VC2 - Providing Awareness in Off-The-Shelf Version Control Systems

Version control systems have been used to help groups of people working at the same or distributed sites to cooperatively create documents. In particular, these systems are very popular in distributed collaborative software development. However, even using these systems, users often perform concurrent changes that require manual conflict resolution. Important causes for this situation are the lack of mutual awareness and coordination, among developers, and reluctance to commit unstable modifications. The paper addresses this problem by providing a tool that integrates with offthe-shelf version control systems and monitors filesystem accesses to relevant files in order to enhance the awareness among developers. With V C users can be aware of uncommitted changes made by remote users; receive request to commit their own changes; be advised to update their local versions. While the final decision is always under user control, the team is made aware of the level of risk when delaying commits and updates. INTRODUCTION The development of team projects often requires the use of tools to aid the coordination and synchronization of work between members. There is a subgroup of these tools known as Version Control (or Revision Control) Systems, many of them are widely established and used, specially in software development projects. These systems divide in two main subgroups: those using the client-server model (CVS, SVN, . . . ) and those using the distributed model (Bazaar, SVK, BitKeeper, . . . ). In the client-server model, the files of a project are located on a server repository. Each user can checkout her local copy from the repository, work locally in the copy and submit changes back to the server. At any time she can also check the server for new versions of files submitted by other users. In the distributed model each user has her own local repository with a copy of the project. She may submit changes to her local repository, and at any time, two or more users may choose to merge their local copies. Motivation While working in a cooperative project under version control tools, users end up concurrently updating the same files. In a client-server system, one of the users will commit first to the central server and the second one will have to incorporate these changes into her files before committing successfully. Version control systems have mechanisms to automatically merge these concurrent changes when different areas of the files are modified. When the same areas of the files are modified, the user has to manually solve the detected conflicts before being able to commit her changes to the central server. The sole usage of version control tools is not enough to avoid this problem. In typical usage scenarios, these situations occur with some frequency. However, solving conflicts may be problematic, specially if the users have made a big number of changes that have not been committed for a long time. These problems may lead users to be reluctant to engage in cooperative projects and even to avoid parallel development [8]. To minimize these problems, users could follow some “best-practices” guidelines, such as regularly keeping their local copies up-to-date and committing as soon as possible, as this approach decreases the probability of conflicts [5]. The problem is that these guidelines are often contrary to good working practices for cooperative projects – e.g. users may only want to commit changes that leave the project in a consistent state, therefore delaying their commits for long periods of time such as days or weeks [13]. The goal of this work is to provide awareness of other users’ activities between synchronization points, helping users to coordinate their work and avoid the need for time consuming conflict resolution tasks. Unlike previous works, where awareness is provided in an application that is different from the application used to edit the shared documents [3, 12] or that require specific editors [14, 11], our solution allows users to continue using their preferred unmodified editors. Awareness information is provided as users access files with any application. Moreover, our solution also does not require any additional infrastructure, building on the existing version control system to propagate the needed information. The remainder of this paper is organized as follows: Related work and the semantics of version control systems are reviewed in the next sections. Section 4 presents the proposed architecture and Section 5 illustrates a typical use case. Implementation details and evaluation are reviewed in Section 6. Discussion and future work in Section 7 is followed by Conclusions. RELATED WORK Awareness information has long been identified as important for the success of cooperative activities by providing users with an understanding of other users’ activities [6]. In groupware systems, a large number of awareness tools have been proposed for synchronous collaboration, such as multi-user scrollbars [1], telepointers and radar views [9], remote screen view [17], etc. These tools allow a user to have some information about the current activities of other users, but they are not appropriate for asynchronous collaboration. Version control systems (e.g. CVS [4], SVN [16] and Bazaar [2]) provide the basic support for team projects, by maintaining and controlling the evolution of file versions for the project files. Basic support for awareness is available, with users being able to include comments when they commit their changes. CVS also includes an additional mechanism that can be used to provide awareness information: CVS watches. When using CVS watches, users must announce their intents of modifying a file beforehand (by executing a special command). Users can register their interest on specific files and be notified by email when someone announces the intent of modifying it. Some tools, such as Eclipse’s Team CVS, automatically issues the required CVS commands when the user starts editing a file and it allows a user to check which users are modifying some file. The BSCW system [3] is a web-based system that includes a version control system to manage shared files. In this system, when some action (check-out, checkin) is executed an event is recorded. The system can present a list of recent event to users when they connect to the system. In [7], the authors introduce a tool for integrating notification and chat with the CVS system. In this system, users are informed when some user commits changes to a file, with events being propagated using an event-dissemination system. Unlike our system, these systems presents no awareness about modifications before they are committed. In State Treemap [12], the authors propose an awareness widget that allows users to visualize which files are being concurrently modified (leading to a potential conflict) and which locally modified files have already been committed (leading to a conflict). This widget has been integrated in a platform for supporting virtual teams of architects. The Palant́ır [14] system provides similar information for files stored in version control systems, relying on an event notification system for propagating information among users. The authors have created wrappers for SVN, RCS and CVS, with events being propagated when edit/update/commit commands are executed. The authors have also developed a plug-in for Eclipse, allowing awareness information to be presented in Eclipse. The Jazz [10] system also provides similar information, as an extension to Eclipse. In Gasper [11], the authors propose a generic mechanism for propagating limited information about changes being performed. Awareness information is provided in the editors in the form of annotations — e.g. if some user is modifying a method in a code file, other users could see an annotation about this fact in their user interface. Several other systems have been designed for providing awareness information in the context of collaborative software development (see [15] for a survey). These systems can be divided in two groups. The first (including basic CVS watches, State Treemap and Palant́ır) requires the use of an additional tool for checking the awareness information. Besides the problem of convincing users to use an additional tool, this approach has the drawback of requiring users to explicitly check for awareness information when they start editing the shared files (as there is no connection between the editing activity and the tool that provides the awareness information). The second group (including Eclipse’s Team CVS watches, Palant́ır, Jazz and Gasper) provides the awareness information in the context of a specific editor. This approach is interesting but it forces users to use a specific editor. Additionally, it requires the plug-ins to be updated when a new version of the editor is released. In our work, we provide awareness information for any editor, thus allowing users to continue using their preferred editors. Additionally, unlike previous works that require specific support from the version control systems or that rely on an additional infrastructure, we propagate the required information using files stored in the version control system. Thus, our approach can be easily deployed with existing version control system. THE SEMANTICS OF VERSION CONTROL In this section we present an overall view of how version control works. At this point we will only consider the centralized model (CVS, SVN, . . . ) and leave the distributed model as future work. In this presentation, to avoid too much complexity we will not consider the adding and removing of files and folders from the repository and the conflicts that may arise from these operations. In version control systems, a user must start by checking out files that are stored in the repository, thus creating a local private copy. At any moment, the user may update her local copy against the latest version stored in the repository. The user may also modify her local copy, one or more times. After modifying her files, the user may commit her changes to the repository. There are two situations that may lead to a conflict if the user modifies her local copy: • The user modifies a file that was remotely modified by some user that has not yet committed her changes to the repository. • The user modifies a file that is outdated against the current version on the repository. Conversely, conflicts may also arise if a remote user modifies an old version of a file that has been locally modified, either it has already been committed or not. In order to help the user avoiding the situations that may lead to conflicts, our tool will provide advance warning about conflict-leading actions. Thus, when a users starts accessing a file that has been modified elsewhere, a notification will be presented to the user suggesting an alternative action. For example, if the user accesses a file that is being concurrently modified by some other user, the user is notified of the fact and may ask the other user to update the file.